https://jira.duraspace.org/browse/ISLANDORA-1459

A quick bit of verification on my own: The transitive Sparql query here appears to work fine on Fedora 3.6.2, with whatever version of Mulgara it packs... Not sure about older versions.

@adam-vessey, sorry, i still have questions if you got some time

your blank node -unnamed variable- query at adam-vessey@d157879#diff-d6fe00e82b5d432596ebff868818181bR480 still does not make sense to me.

If you are quering for "every object that has a collection CMODEL" UNION "(not named variable) every object that has as model an -object- that has a collection CMODEL, you get the same result as using the first query without union because the last one matches nothing.

would match only if it had any of this forms

1. [fedora-model:hasModel info:fedora/fedora-system:ContentModel-3.0]
2. [fedora-model:hasModel info:fedora/fedora-system:FedoraObject-3.0]
3. [fedora-model:hasModel ?amodel] -- gets you both, means double

In this cases: you will get every object in the RI that has a content model, second one every object that is a fedora object, third one duplicated 1 + 2. Any of these will also return collection objects. So if this would be the intention…not sure why do you explicitly get collection cmodel objects.

Since every object in fedora has a model, i suppose the idea is to get also the non-collection objects ? I don't understand, sorry, need some clarification or explanation, is there an edge case?.

Also i think the SELECT needs a "distinct"

Thanks, sorry for being so picky/hard to understand 😬

@DiegoPino Just because a variable is not named does not mean it is not bound. The syntax is short-hand for a single step of transitivity. See http://www.w3.org/TR/rdf-sparql-query/#QSynBlankNodes, particularly the section about using this structure in square brackets as an object.

Once upon a time, we had taken a stab at content model inheritance, so we had "special" collection content models which <fedora-model:hasModel>'d the core <info:fedora/islandora:collectionCModel>... We're trying to implement an equivalent query here, not to change the logic itself (save for a slight fix).

As for making it DISTINCT... Having duplicates in the response here would not affect later processing in any great amount (and should only happen on these object which might have both a "special" collection model in addition to the core one (or chain of both <fedora-rels-ext:isMemberOf> and <fedora-rels-ext:isMemberOfCollection> to the same object)). The results of this query are just fed into a disjunction we query of Solr... I could see throwing the REDUCED hint on, so the triplestore can remove duplicates if it wants, but requiring it just puts extra load on the triplestore... I prefer to abuse Solr (which would probably quickly optimize away searching for the same phrase multiple times). :P

@adam-vessey, thanks for the clarification on the use case/legacy compat. need, i know blanks are bound in the solution and sparql syntax is luckily (or sadly sometimes) not new for me, but had never guessed that there are some objects out there that really match
?child <fedora-model:hasModel> _:b1 .
_:b1 <fedora-model:hasModel> <info:fedora/islandora:collectionCModel>

So we had islandora cmodel inheritance in the past, nice to know and that we still care for those.

Your DISTINCT argument makes also sense.
Thanks again for taking the time to expand on this.